\section{Aspetti Implementativi}
\subsection{Strutturazione del codice}
\subsubsection{Packages}
Il codice \`{e} strutturato in 6 differenti packages, per permettere al meglio la divisione dei ruoli e delle classi. Questi package sono:
\begin{itemize}
\item \textbf{unibo.lsb.communication} - al suo interno ci sono tutte le classi Java che permettono di realizzare le comunicazioni tra i vari processi durante il gioco e nella fase di registrazione al server. Diagramma in figura \ref{fig:classComm}.
\item \textbf{unibo.lsb.exception} - contiene 2 classi, una che estende l'eccezione base per aggiungere alcune utili informazioni per il progetto, e un'altra che contiene alcune costanti utilizzate all'interno del codice.
\item \textbf{unibo.lsb.graphic} - questo package contiene tutte le classi che permettono di creare la grafica o che vengono utilizzate dalle finestre per fornire informazioni sullo stato di avanzamento del gioco.
\item \textbf{unibo.lsb.logic} - in questo package troviamo tutte le classi che realizzano la logica vera e propria del gioco, dunque le regole, gli oggetti che vengono utilizzati durante una partita e le classi che permettono di realizzare i giocatori. Diagramma in figura \ref{fig:classLogic}.
\item \textbf{unibo.lsb.server} - in questo package ci sono le classi che realizzano l'unica parte centralizzata del progetto, ovvero il server di registrazione. Diagramma in figura \ref{fig:classServer}.
\item \textbf{unibo.lsb.tokyo} - questo package \`{e} composto da un'unica classe, il cui scopo \`{e} quello di far partire effettivamente il gioco aprendo la finestra principale.
\end{itemize}

\subsection{Scelte implementative}
In fase di progettazione, e quindi successivamente in fase di sviluppo, abbiamo deciso di fare un uso abbondante ma mirato del design pattern Singleton, questo poich\`{e} il progetto include alcuni oggetti che devono essere acceduti da diverse parti del codice senza dover essere ricreati tutte le volte, in quanto contengono informazioni importanti valide per tutta la durata del gioco.\\
Alcuni esempi di questo utilizzo sono:
\begin{itemize}
\item \textbf{unibo.lsb.logic.PlayerSelfSingleton} - lo scopo di questa classe \`{e} quello di mantenere un'istanza comune e unica che contenga tutte le informazioni sul giocatore, come ad esempio il nome all'interno del gioco, l'IP dal quale si sta giocano e l'avatar attraverso il quale si \`{e} riconosciuti durante il gioco stesso.
\item \textbf{unibo.lsb.graphic.GameTableWindowSingleton} - questa classe mantiene l'istanza della finestra principale di gioco. Tutti gli aggiornamenti grafici, come ad esempio l'aggiunta di penalit\`{a}, la rimozione di giocatori, il passaggio di turno, vengono notificati all'utente usando questa classe per reperire la finestra attualmente visualizzata, e agendo poi su di essa in modi diversi a seconda della notifica da eseguire.
\item \textbf{unibo.lsb.communication.InformationSingleton} - questa classe mantiene un'istanza unica e comune di due importanti oggetti del nostro gioco, che sono:
	\begin{itemize}
		\item Game
		\item PlayersTable
	\end{itemize}
L'oggetto di tipo Game contiene tutte le informazioni sul gioco prima che questo sia iniziato, come ad esempio la lista dei giocatori e il nome del gioco stesso, mentre invece la PlayersTable contiene le informazioni sul gioco in corso, quindi il numero di penalit\`{a} di ogni giocatore, il turno corrente e cos\`{i} via.
\end{itemize}

\subsection{Diagrammi}
\subsubsection{Diagramma delle classi}

Nelle figure \ref{fig:classComm}, \ref{fig:classLogic} e \ref{fig:classServer} sono rappresentati i diagrammi UML delle classi suddivisi secondo i package descritti precedentemente. Vengono rappresentati solo quelli relativi alla logica del gioco e alle comunicazioni, omettendo le parti marginali del progetto.

\begin{figure}[!htp]
\centering
\hspace*{-1.5cm}
\includegraphics[width=1.2 \textwidth]{imgs/class_comm2.png}
\caption{diagramma delle classi: package di comunicazione.}\label{fig:classComm}
\end{figure}

\begin{figure}[!htp]
\centering
\hspace*{-1.5cm}
\includegraphics[width=1.2 \textwidth]{imgs/class_logic.png}
\caption{diagramma delle classi: package con le classi relative alla logica di gioco.}\label{fig:classLogic}
\end{figure}

\begin{figure}[!htp]
\centering
\hspace*{-1.5cm}
\includegraphics[width=1.2 \textwidth]{imgs/class_server.png}
\caption{diagramma delle classi: package contenente il servizio di registrazione e creazione delle partite.}\label{fig:classServer}
\end{figure}

\subsubsection{Diagramma delle interazioni}
In figura \ref{fig:rcvStatus} \`e mostrato il flusso di operazioni svolte quando si riceve un'informazione sullo stato di un giocatore (tipicamente, che questo \`e crashato). Sostanzialmente, vengono aggiornati l'oggetto PlayersTable, e l'oggetto che costituisce la finestra grafica. Entrambi gli oggetti vengono ottenuti accendendo a relativo oggetto singleton (abbiamo mostrato esplicitamente l'accesso al singleton solo per il primo oggetto). Seguono lo schema di questo metodo remoto, molto semplice, altri metodi remoti quali il metodo deputato a ricevere messaggi testuali, e quello che riceve l'informazione su chi sia il giocatore che ha vinto.\\
In figura \ref{fig:rcvTurn} sono riassunte le azioni nel caso di ricezione di un'informazione relativa al turno. Il giocatore aggiorna il suo stato con la nuova informazione, e se il turno \`e passato a lui gioca e manda il risultato della sua giocata al successivo nodo vivo nell'anello, notificando allo stesso tempo l'accaduto agli altri nodi con un messaggio testuale. Le comunicazioni in uscita sono gestite tutte dalla classe CommunicationLocal.\\
Un giocatore riceve un turno che corrisponde al suo solo se il giocatore prima di lui \`e crashato o ha terminato le sue penalit\`a ed \`e quindi uscito dal gioco. Se viene ricevuto un turno, si tirano i dadi senza vincolo di punteggio minimo, quindi \`e legittimo aspettarsi ci sia senza eccezioni un nuovo dado da mandare al nodo successivo.\\
In figura \ref{fig:rcvPenalty} \`e rappresentata la risposta alla ricezione di una penalit\`a. Se il giocatore che riceve la penalit\`a \`e lo stesso al quale la penalit\`a \`e rivolta, questi non si limita ad aggiornare le proprie informazioni. Se con la nuova penalit\`a il giocatore \`e escluso dal gioco, passa il turno al primo giocatore vivo dopo di lui, notificando a tutti i partecipanti al gioco(lui compreso) il nuovo detentore del turno. Se invece \`e ancora in gioco, notifica agli altri giocatori che detiene il turno, gioca, e manda i dadi al successivo giocatore vivo.\\
Infine, la figura \ref{fig:rcvDice} riassume la logica i ci\`o che avviene quando vengono ricevuti dei dadi. Abbiamo omesso di rappresentare le costanti chiamate alla grafica e gli invii di messaggi di testo agli altri giocatori, per rendere il diagramma pi\`u leggibile.
Chi riceve i dadi ha il turno, e lo notifica agli altri giocatori. Se accetta i dadi, li ritira e manda i nuovi dadi al successivo giocatore vivo. Se accetta un dado dichiarato 21, prima di tutto notifica la penalit\`a che ha ricevuto, poi se \`e ancora in gioco (non ha raggiunto il numero massimo di penalit\`a) lancia i dadi e li manda, altrimenti notifica agli altri giocatori che il turno \`e del successivo giocatore vivo. Se invece dubita, notifica agli altri la penalit\`a e chi l'ha presa (se lui o il giocatore che gli ha passato i dadi). Se chi ha preso penalit\`a era il giocatore precedente ma questi \`e nel frattempo crashato, il giocatore corrente ha il turno e lo notifica a tutti compreso se stesso. Se invece \`e il giocatore corrente ad aver preso penalit\`a, se \`e ancora nel gioco tira i dadi e li manda avanti.
\begin{figure}[!htp]
\centering
\hspace*{-1.5cm}
\includegraphics[width=1.2 \textwidth]{imgs/receiveStatus.pdf}
\caption{Diagramma di sequenza che rappresenta la ricezione di informazioni sullo stato di un giocatore.}\label{fig:rcvStatus}
\end{figure}
\begin{figure}[!htp]
\centering
\hspace*{-1.5cm}
\includegraphics[width=1.2 \textwidth]{imgs/receiveTurn.pdf}
\caption{Diagramma di sequenza sulla ricezione di informazioni su chi detiene il turno.}\label{fig:rcvTurn}
\end{figure}
\begin{figure}[!htp]
\centering
\hspace*{-1.5cm}
\includegraphics[width=1.1\textwidth]{imgs/receivePenalty.pdf}
\caption{Diagramma di sequenza relativo alla ricezione di una penalit\`a.}\label{fig:rcvPenalty}
\end{figure}
\begin{figure}[!htp]
\centering
\includegraphics[width=\textwidth]{imgs/receiveDice.pdf}
\caption{Diagramma di sequenza che rappresenta la ricezione dei dadi.}\label{fig:rcvDice}
\end{figure}
\clearpage

\subsection{Reazione ai crash}
Il nostro progetto resiste al crash di n-1 giocatori, anche contemporaneo, fino ad eleggere il vincitore.\\
Abbiamo cercato di creare processi il pi\`{u} possibile paritari fra loro, infatti il nostro leader \`{e} sempre colui che ha il turno attuale.\\
Quando parte il gioco, ogni giocatore fa partire un polling verso il giocatore immediatamente successivo a se stesso. Ogni 0,2 secondi controlla che questo giocatore sia vivo e che non abbia superato il numero massimo di penalit`{a}, e in caso negativo procede a compiere alcune operazioni descritte di seguito.\\
Tutte le volte che un giocatore viene trovato in stato di crash o eliminato, viene chiamato il metodo \textit{reactOnDeadPlayer}, che si preoccupa di notificare il nuovo stato del giocatore a tutti i partecipanti, e nel caso in cui che quel giocatore fosse il leader, anche il turno.\\
Abbiamo preferito controllare non solo lo stato di crash, ma anche quello di massima penalit\`{a}, per il fatto che un giocatore che viene eliminato dal gioco \`{e} pi\`{u} propenso a lasciarlo. In questo modo, noi anticipiamo questo possibile comportamento modificando il polling facendolo passare al giocatore successivo.